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Foreword 

The  Federal  Information  Processing  Standards  Publication  Series  of  the  National  Bureau  of  Standards 
is  the  official  publication  relating  to  standards  adopted  and  promulgated  under  the  provisions  of  Public  Law 
89-306  (Brooks  Act)  and  under  Part  6  of  Title  15,  Code  of  Federal  Regulations.  These  legislative  and 
executive  mandates  have  given  the  Secretary  of  Commerce  important  responsibilities  for  improving  the 
utilization  and  management  of  computers  and  automatic  data  processing  in  the  Federal  Government.  To 
carry  out  the  Secretary’s  responsibilities,  the  NBS,  through  its  Institute  for  Computer  Sciences  and 
Technology,  provides  leadership,  technical  guidance,  and  coordination  of  Government  efforts  in  the 
development  of  guidelines  and  standards  in  t’  se  areas. 

In  May  1974,  the  Comptroller  General  of  the  United  States,  in  a  report  to  the  Congress,  noted  that  the 
cost  for  Federal  data  collection  and  data  handling  activities  is  estimated  to  exceed  $5  billion  annually.  With 
such  an  investment.  Government  agencies  r,re  striving  to  reduce  redundant  data  resources,  and  to  improve 
the  utility  of  existing  data  resources.  A  , /ell-developed  and  properly  utilized  Data  Dictionary  System  (DDS) 
will  help  Federal  agencies  eliminate  unnecessary  data  gathering,  reduce  costs,  and  improve  information 
systems’  effectiveness.  NBS  makes  available  this  guideline  to  assist  Federal  agencies  in  planning  and  using 
a  DDS. 


James  H.  Burrows,  Director 
Institute  for  Computer  Sciences  and  Technology 


Abstract 

This  guideline  provides  assistance  to  Federal  ADP  Management  and  technical  staff  in  planning  and  using  Data  Dictionary 
Systems  (DDS’s).  A  DDS  is  a  computer  software  system  that  is  used  to  assist  in  organization-wide  data  management,  without  restriction 
to  computer  data.  This  document  describes  the  capabilities  of  a  DDS;  addresses  selection  considerations;  provides  guidance  for 
preimplementation  planning,  including  such  management  issues  as  DDS  policies  and  budgeting,  data  standardization  and  control,  and 
coordination  of  the  DDS  contents.  The  document  also  presents  initiation  and  operation  considerations  for  using  a  DDS. 
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management  system;  documentation;  Federal  Information  Processing  Standards  Publication;  software. 
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Federal  Information  Processing  Standards  Publications  are  issued  by  the  National  Bureau  of  Standards  pursuant  to  the  Federal  Property  and 
Administrative  Services  Act  of  1949,  as  amended.  Public  Law  89-306  (79  Stat.  1127),  Executive  Order  11717  (38  FR  12315,  dated  May  11,  1973) 
and  Part  6  of  Title  15  Code  of  Federal  Regulations  (CFR). 

Name  of  Guideline:  Guideline  for  Planning  and  Using  a  Data  Dictionary  System. 

Category  of  Guideline:  Software,  Data  Management  Applications. 

Explanation:  This  guideline  describes  the  capabilities  of  a  data  dictionary  system,  discusses  selection 
considerations,  and  provides  guidance  for  preimplementation  planning,  implementation,  and  operational  use  of  the 
DDS. 

Approving  Authority:  U.S.  Department  of  Commerce,  National  Bureau  of  Standards  (Institute  for  Computer 
Sciences  and  Technology). 

Maintenance  Agency:  U.S.  Department  of  Commerce,  National  Bureau  of  Standards  (Institute  for  Computer 
Sciences  and  Technology). 

Cross  Index: 

a.  Federal  Information  Processing  Standards  Publication  (FIPS  PUB)  28,  Standardization  of  Data  Elements 
and  Representation. 

b.  Federal  Information  Processing  Standards  Publication  (FIPS  PUB)  38,  Guidelines  for  Documentation  of 
Computer  Programs  and  Automated  Data  Systems. 

c.  Federal  Information  Processing  Standards  Publication  (FIPS  PUB)  42-1,  Guideline  for  Benchmarking  ADP 
Systems  in  the  Competitive  Procurement  Environment. 

d.  Federal  Information  Processing  Standards  Publication  (FIPS  PUB)  45,  Guide  for  the  Development, 
Implementation  and  Maintenance  of  Standards  for  the  Representation  of  Computer  Processed  Data  Elements. 

e.  Federal  Information  Processing  Standards  Publication  (FIPS  PUB)  64,  Guidelines  for  Documentation  of 
Computer  Programs  and  Automated  Data  Systems  for  the  Initiation  Phase. 

f.  Federal  Information  Processing  Standards  Publication  (FIPS  PUB)  67,  Guideline  for  Selection  of  Data  Entry 
Equipment. 

g.  Federal  Information  Processing  Standards  Publication  (FIPS  PUB)  77,  Guideline  for  Planning  and 
Management  of  Database  Applications. 

Applicability:  This  guideline  is  a  basic  reference  document  for  general  use  by  Federal  departments  and  agencies  in 
the  implementation  and  use  of  a  data  dictionary  system. 

Implementation  Schedule:  This  guideline  should  be  consulted  when  Federal  agencies  are:  considering  acquiring 
or  developing  data  dictionary  systems;  developing  policies  and  procedures  for  implementing  and  using  data  dictionary 
systems;  or  reviewing  the  current  use  of  data  dictionary  systems. 

Specifications:  Federal  Information  Processing  Standard  76  (FIPS  PUB  76),  Guideline  for  Planning  and  Using  a 
Data  Dictionary  System  (affixed). 

Definitions:  The  following  definitions  are  used  in  this  document: 

Computer  program.  A  series  of  instructions  or  statements,  in  a  form  acceptable  to  a  computer,  prepared  to 
achieve  a  certain  result. 
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Software.  (ISO)  Computer  programs,  procedures,  rules,  and  possibly  associated  documentation  concerned  with 
the  operation  of  a  data  processing  system. 

Data  dictionary  system.  A  computer  software  system  used  to  record,  store,  and  process  information  about  an 
organization’s  significant  data  and  associated  data  processing  functions. 

Qualifications:  This  guideline  represents  recommended  practices  in  planning  for  and  using  data  dictionary 
systems.  They  are  not  offered  as  unqualified  recommendations.  In  applying  this  guideline,  it  is  important  to  bear  in 
mind  that  data  dictionary  systems  may  serve  many  different  purposes  and  management  objectives.  Therefore,  no 
single  approach  for  their  application  can  be  recommended  for  every  agency.  Each  Federal  agency,  office,  or  project 
should  investigate  the  specific  circumstances  that  would  warrant  the  installation  and  use  of  a  DDS. 

Where  to  Obtain  Copies  of  the  Guideline:  Copies  of  this  publication  are  for  sale  by  the  National  Technical 
Information  Service,  U.S.  Department  of  Commerce,  Springfield,  Virginia  22161.  When  ordering,  refer  to  Federal 
Information  Processing  Standards  Publication  76  (FIPS-PUB-76),  and  title.  When  microfiche  is  desired,  this 
should  be  specified.  Payment  may  be  made  by  check,  money  order,  American  Express  Card,  or  NTIS  Deposit 
Account. 
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Guideline  in  Perspective 


1.  INTRODUCTION 


The  purpose  of  this  guideline  is  to  assist  Federal  ADP  management  and  technical  staff  in  planning  and  using 
Data  Dictionary  Systems  (DDS’s). 

A  Data  Dictionary  System  is  a  computer  software  system  used  to  record,  store,  and  process  information  about  all 
of  an  organization’s  significant  data  entities  and  associated  data  processing  functions.  The  DDS  can  benefit  an  entire 
Federal  agency  or  an  individual  project.  The  DDS  provides  Federal  ADP  managers  with  a  central  source  of 
information  about  the  organization’s  data  resources,  an  automated  documentation  tool,  and  an  aid  in  system  design 
and  development. 

The  term  “data  dictionary,”  which  stems  from  the  early  applications  that  simply  catalogued  and  defined  data 
elements,  is  no  longer  completely  appropriate  and  descriptive,  but  nevertheless  continues  to  be  widely  used,  and  will 
be  used  in  this  publication. 

This  publication  addresses  selection  considerations,  management  issues,  and  initiation  and  operation 
considerations  for  using  a  DDS.  In  applying  this  guideline,  it  is  important  to  bear  in  mind  that  a  DDS  may  serve 
many  different  purposes  and  management  objectives.  Therefore,  no  single  approach  for  its  application  can  be 
recommended  for  every  agency.  Each  agency,  office,  or  project  should  investigate  the  specific  circumstances  that 
would  warrant  the  installation  and  use  of  a  DDS.  This  document  should  be  used  in  conjunction  with  Federal 
Information  Processing  Standards  Publication  numbers  28  (on  data  elements  and  representations),  38  and  64  (on 
documentation),  42-1  (on  benchmarking),  45  (on  standard  data  elements),  67  (on  data  entry),  and  77  (on  application 
management). 

This  guideline  provides  recommended  practices  in  planning  for  and  using  a  DDS.  These  practices  are  not  offered 
as  unqualified  recommendations.  Guidelines  are  not  procedural  steps  that  can  be  followed  as  a  “recipe”  with 
successful  results.  Instead,  they  are  a  discussion  of  good  practices  associated  with  areas  of  concern.  In  this  sense, 
guidelines  are  useful  as  a  checklist,  and  to  some  degree,  they  identify  areas  where  special  competence,  expertise,  or 
particular  attention  is  indicated. 


Organization  of  FIPS  PUB  76 


The  remainder  of  this  document  is  organized  as  follows: 

*  Section  2  describes  the  capabilities  of  a  DDS,  types  of  DDS’s  available,  and  roles  of  a  DDS  in  the  overall 
information  processing  environment. 

*  Section  3  discusses  selection  considerations,  including  technical  and  economical  factors. 

*  Section  4  presents  preimplementation  planning  guidelines  which  address  policy  considerations,  budget,  data 
standardization,  control  and  coordination  of  DDS  contents,  technical  support,  and  training. 

*  Section  5  provides  guidelines  for  implementing  and  using  a  DDS. 


2.  DATA  DICTIONARY  SYSTEM  CAPABILITIES 


2.1  Background 


The  Federal  Government,  like  all  large  organizations,  collects  a  very  large  quantity  of  data  for  its  operations  and 
decisionmaking.  Data  collection  and  handling  are  expensive,  and  poor  quality  data  and  lack  of  quality  control  in  data 
collection  and  handling  can  impede  Government  services  and  decisionmaking.  For  example,  problems  exist  when: 

*  Data  is  collected  redundantly  by  different  departments,  or  data  is  collected  anew  instead  of  finding  and  using 
equivalent  existing  data; 

*  Data  is  collected  or  recorded  inconsistently;  for  example,  different  measuring  units  or  codes  are  applied  when 
similar  data  is  collected  by  two  different  groups. 


The  Data  Dictionary  System  (DDS),  when  consistently  and  conscientiously  used  by  data  management  and  computing 
personnel,  will  reduce  problems  such  as  these. 


The  DDS  is  itself  an  information  system  about  all  of  an  organization’s  significant  data  and  data  processing 
itities  [1,2,3]*.  Pertinent  entities  include  individual  data  items  or  elements  (such  as  client  name  or  parts  on  hand). 


Numbers  in  brackets  indicate  literature  references  at  the  end  of  this 


paper. 
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data  groups  (such  as  client’s  dependents),  data  collection  forms,  records,  files,  databases,  programs,  systems,  reports,^ 
user  procedures,  and  users.  The  content  of  the  DDS,  often  called  “metadata  but  usually  called  simply  the  data^ 
dictionary,”  consists  of  formal  descriptions  of  the  pertinent  entities.  An  individual  DDS  entry,  hereafter  called  an 
entity  description,  therefore  contains  important  information  about  a  named  entity  (for  example,  the  data  element 
CLIENT-NAME),  but  does  not  contain  actual  instances  of  the  entity  (that  is,  all  existing  client  names).  Rather,  the 
actual  instances  exist  outside  of  the  DDS;  as  examples,  they  are  data  values  stored  in  a  database  or  on  a  magnetic  tape 
located  in  a  vault,  or  they  are  offices  or  people  within  the  organization. 

A  DDS  may  be  used  effectively  to  describe  data  elements  and  other  entities  that  do  not  involve  computer 
processing,  as  well  as  to  describe  entities  which  involve  computer  applications.  A  fully  developed  data  dictionary  for 
an  organization  or  project  is  a  catalog  of  its  data  resources.  A  DDS  is  also  a  computer  database  that  fully  documents 
the  organization’s  data  collection,  processing,  handling,  and  dissemination  activities.  A  DDS  is  therefore  an  automated 
documentation  and  information  retrieval  system  to  support  organization-wide  data  management,  without  limitation  to 
computer  data.  A  DDS  may  have  more  substantial  capabilities  as  an  active  component  of  computer  applications,  as 
will  be  described  later  in  this  section. 

To  summarize,  a  DDS  provides  capability  for: 

1.  Specifying  the  type  of  an  entity,  such  as  a  form,  a  data  element,  or  a  computer  file. 

2.  Uniquely  naming  an  entity  and  describing  it  in  appropriate  terms,  such  as  the  range  of  values  of  a  data 
element  or  a  narrative  description  of  its  meaning. 

3.  Specifying  the  flow  and  the  storage  locations  of  data  entities  within  the  organization  or  within  the  computer 
installation. 

4.  Specifying  associations  and  relationships  among  the  data  entities;  for  example,  appearance  on  the  same 
form,  or  derivation  of  an  entity  from  another. 

5.  Specifying  and  producing  reports  about  the  data  dictionary  content,  such  as  a  listing  of  all  data  elements  or 
a  cross-reference  listing  of  all  entities. 


2.2  Types  of  Entity  Descriptions 

A  DDS  provides  a  prescribed  set  of  different  entity  types;  each  type  has  a  prescribed  set  of  attributes.  Thes^ 
attributes  describe  an  entity  of  the  given  type.  An  entity  description  is  entered  into  the  data  dictionary  through  the 
DDS  as  one  or  more  text  lines  that  name  the  entity  and  its  type,  and  give  values  for  the  applicable  attributes.  The 
entity  name,  type  designation,  and  other  attributes  must  follow  the  prescribed  conventions  of  the  DDS.  For  example, 
an  entity  name  may  consist  of  from  1  to  30  alphanumeric  characters  only;  the  type  designation  must  be  one  of  the 
established  codes,  such  as  EL  for  data  element  or  SD  for  source  document.  For  some  entity  types,  an  available 
attribute  may  be  a  text  field,  say  up  to  150  characters,  for  entering  a  narrative  description  pertinent  to  each  entity. 

A  DDS  could  also  provide  the  capability  for  the  user  to  define  additional  types  of  entities  and  their  attributes, 
and  to  enter  entity  descriptions  according  to  these  user-defined  types. 

The  conventions  and  attributes  of  entity  descriptions  are  especially  important  in  assessing  a  DDS.  Data 
descriptions  are  essential  to  almost  all  computer  programs.  For  example,  a  COBOL  application  program  requires  a 
DATA  DIVISION.  A  database  management  system  (DBMS)  requires  a  database  schema  expressed  in  its  Data 
Definition  Language  (DDL).  Central  storage  of  data  descriptions  under  a  DDS  can  improve  data  standardization  and 
integrity  control  considerably,  if  the  DDS  can  compile  and  output  selected  data  descriptions  in  the  form  and  content 
required  by  other  software.  Many  DDS  packages  are  specifically  designed  for  this  purpose,  so  their  data  descriptions 
do  incorporate  the  necessary  information  at  least  for  one  software  system  such  as  a  given  DBMS  or  for  a  category  of 
software  such  as  COBOL  programs.  However,  usually  the  syntax  of  the  DDS  language  and  entity  descriptions  differs 
substantially  from  the  DBMS  DDL  or  the  COBOL  DATA  DIVISION. 

2.3  Types  of  DDS 

There  are  two  principal  ways  to  classify  the  wide  range  of  capabilities  and  implementations  found  in  present 
DDS’s.  One  way  is  according  to  the  DDS  capability  to  provide  data  entity  descriptions  to  other  software.  In  this 
respect,  the  DDS  could  be  called  passive  or  active.  Another  classification  is  according  to  the  dependence  of  the  DDS 
on  other  software  for  implementing  its  functions.  On  this  basis,  the  DDS  may  be  classified  as  either  stand-alone  or 
dependent.  ^ 

2.3.1  Passive  and  Active  DDS.  A  passive  DDS  is  an  information  management  system  used  only  by  personnel  to 
enter  or  retrieve  entity  descriptions.  With  a  passive  DDS,  descriptions  of  the  same  data  will  exist  concurrently  in 
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other  software  such  as  COBOL  programs.  Changes  in  the  DDS  content  do  not  automatically  produce  corresponding 
changes  in  the  other  data  descriptions,  and  vice  versa.  Thus  a  passive  DDS  does  not  itself  control  the  organization’s 
data,  although  it  would  assist  manual  procedures  to  do  so. 

An  active  DDS,  through  software  interfaces  and  computer  operating  procedures,  provides  the  ONLY  source  for 
data  descriptions  to  other  processing  components  such  as  compilers,  assemblers,  and  DBMS’s.  The  active  DDS 
enforces  data  standards  and  usage  throughout  the  organization  and  its  computer  applications.  For  example,  an  active 
DDS  could  produce  the  DATA  DIVISION  for  any  COBOL  program  from  dictionary  information  and  parameters 
supplied  in  the  job  stream.  The  descriptive  text  would  be  interspersed  with  the  program  source  text  and  passed  to  the 
COBOL  compiler;  or  the  descriptive  text  is  placed  into  a  COBOL  “Copylib,”  and  then  passed  to  the  compiler.  Here 
the  DDS  is  said  to  be  active  with  respect  to  the  COBOL  compiler. 

2.3.2  Stand-Alone  and  Dependent  DDS.  A  stand-alone  DDS  is  self-contained;  that  is,  its  functions  are  performed 
without  relying  on  any  other  general  purpose  software  such  as  a  DBMS.  A  stand-alone  DDS  may  be  passive  or  active. 
Most  of  the  current  stand-alone  implementations  have  available  the  features  that  make  them  active  when  invoked  by  a 
user. 

A  dependent  DDS  is  specifically  tailored  to  operate  in  conjunction  with  another  general  purpose  software  system, 
usually  a  DBMS.  It  requires  the  DBMS  facilities  to  perform  DDS  functions.  In  some  cases,  the  dependent  DDS  is 
implemented  as  a  DBMS  application,  using  only  DBMS  facilities.  Such  an  intimate  connection  does  not  necessarily 
mean  that  a  dependent  DDS  is  automatically  active  with  respect  to  the  DBMS.  However,  it  may  be  easier  to  invoke 
facilities  that  would  make  the  DDS  active. 


2.4  Roles  of  the  DDS 

As  the  central  repository  of  current  and  accurate  information  about  an  organization’s  data  and  its  handling,  a 
DDS  can  assist  in  a  wide  range  of  management  and  technical  tasks.  The  following  indicates  different  areas  where  use 
of  a  DDS  is  appropriate. 

2.4.1  Data  Resource  Management.  Because  of  the  impact  of  government-directed  data  collection  on  the  private 
sector  and  also  the  increasing  costs  of  labor-intensive  data  handling,  government  agencies  are  striving  to  reduce 
redundant  data  collection  and  to  improve  the  utility  of  existing  data  resources  [4],  A  well-developed  DDS  provides 
high  visibility  to  similar  data  elements,  forms,  and  collection  procedures,  and  reliably  identifies  current  holdings  [5,6]. 
Officials  who  control  data  collection  projects  or  data  usage  can  use  DDS  reports  to  eliminate  unnecessary  data 
gathering  and  to  redirect  data  management  activities  to  reduce  costs  and  improve  overall  effectiveness  [7,8,9]. 

2.4.2  Data  Standardization.  Data  collected  for  one  purpose  often  cannot  serve  another  because  inappropriate 
standards  were  used  in  the  original  collection.  NBS  is  producing  selected  government-wide  data  standards  under  its 
Data  Element  and  Representation  Standards  Program,  but  each  agency  must  also  undertake  data  standardization  for 
its  unique  needs  [10].  A  DDS  can  be  used  to  record  the  data  standards  applied  to  every  data  element,  and  to  assist 
auditing  to  assure  that  the  required  standards  are  in  effect.  Moreover,  an  active  DDS  can  be  used  as  the  source  of 
established  data  standards  when  needed  by  various  activities,  and  also  can  participate  in  computer  processes  that  edit 
and  validate  data  against  the  established  standards. 

2.4.3  System  Development  and  Documentation.  The  DDS  is  a  valuable  documentation  tool  over  the  entire  life  cycle 
of  systems,  procedures,  and  software  [11,12,13].  In  some  cases,  the  DDS  can  be  used  as  a  security  enforcement 
mechanism. 

During  the  requirements  definition  of  new  systems,  information  is  collected  about  data,  processes,  and  data 
usage  requirements.  Descriptions  of  these  requirements  can  be  stored  in  the  DDS,  and  used  in  conjunction  with 
analysis  and  design  software  to  analyze  various  aspects  of  the  system  under  development.  Subsequent  changes  to  the 
requirements  definitions  can  be  easily  made  and  reported  to  all  affected  offices  and  personnel,  thereby  minimizing 
errors  due  to  inadvertent  omissions  or  changes. 

Using  the  current  descriptions  of  the  entities  and  their  relationships,  an  active  DDS  can  produce  data 
descriptions  for  individual  software  modules.  When  used  in  conjunction  with  design  aids,  the  DDS  can  produce 
descriptions  of  alternative  file  or  database  designs  for  evaluation. 

During  development,  the  DDS  can  produce  data  division  and  documentation  for  application  programs.  It  can  also 
produce  the  actual  DATA  DIVISION  for  COBOL  programs,  or  the  DDL  for  the  DBMS. 
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During  software  testing,  the  DDS  can  help  generate  the  test  data  by  using  the  entity  descriptions  which  already 
exist  in  the  dictionary.  During  modification  and  maintenance,  the  DDS  is  useful  in  determining  the  effect  of  proposed 
changes  on  other  entities  in  the  operational  environment. 

The  DDS  can  assist  in  producing  documentation  concurrently  with  development,  rather  than  after  the  fact.  As 
applications  are  designed  and  programs  are  written,  the  pertinent  entity  descriptions,  entered  in  the  DDS,  will 
eliminate  the  need  to  divert  manpower  later  for  documentation  after  the  application  is  completed. 

2.4.4  Conversion.  Lack  of  documentation  is  undoubtedly  the  primary  barrier  to  economical  and  complete 
conversion  of  applications  from  one  computer  system  to  another.  Poor  documentation  can  force  an  agency  to  redesign 
a  system.  Inappropriate  or  fragmented  documentation  can  impede  the  use  of  automated  conversion  aids.  Consistent 
and  thorough  use  of  a  DDS  can  substantially  eliminate  documentation  problems  and  facilitate  conversion.  Most 
important,  an  active  DDS  can  provide  the  data  descriptions  necessary  to  drive  automated  file  conversion  software  [14]. 

2.5  Potential  Benefits 

The  benefits  of  a  DDS  do  not  depend  upon  its  being  used  government-wide  or  agency-wide.  A  DDS  can  benefit  a 
single  bureau,  facility.  Federal  program,  or  computer  application.  Using  a  DDS  provides  economic  and  technical 
benefits.  A  DDS  may  provide  immediate  savings,  or  it  may  facilitate  a  continuing  technical  process  by  making  it 
easier  or  more  reliable  to  perform.  To  summarize  the  benefits: 

*  Better  control  of  the  organization’s  data  resources  through  improved  (i.e.,  centralized,  rigorous,  and 
standardized)  data  definitions,  data  handling  and  data  collection  procedures. 

*  Improved  transportability  of  data  and  software  between  computing  environments  through  standardized  data 
and  data  definitions. 

*  Improved  documentation  for  databases,  programs,  and  systems. 

*  Automatic  compilation  of  data  definitions  to  be  included  in  application  programs  or  in  DBMS  database 
definitions. 

*  Increased  security  and  access  control  for  the  database  environment. 

*  Effective  aid  to  software  development,  modification,  and  maintenance  through  configuration  management  of 
system  components  of  data  and  programs. 

*  Increased  cost-effective  use  of  resources  throughout  the  system  development  life  cycle. 

3.  SELECTION  CONSIDERATIONS 

Federal  procurements  are  governed  by  the  Federal  Procurement  Regulations  (FPR)  published  under  Title  41  of 
the  Code  of  Federal  Regulations  (CFR)  as  Chapter  1.  Government-wide  Federal  Property  Management  Regulations 
(FPMR)  applicable  to  Automatic  Data  Processing  are  published  as  Subchapter  F  of  Chapter  101  of  Title  41  CFR.  In 
addition  to  Government-wide  rules,  many  agencies  have  their  own  supplementary  regulations  and  procedures. 
Consultation  with  the  procurement  authority  in  the  particular  agency  is  recommended  prior  to  initiating  a  procurement 
action  to  ensure  compliance  with  all  applicable  rules,  regulations,  and  procedures. 

The  purpose  of  this  section  is  to  address  the  technical  and  economic  issues  that  Federal  agencies  must  consider 
when  acquiring  a  DDS.  These  considerations  are  not  intended  to  be  a  rigorous  set  of  evaluation  criteria  for  selection 
of  a  DDS.  Prior  to  obtaining  a  DDS,  the  following  must  be  addressed: 

*  Application  scope, 

*  Technical  factors,  and 

*  Economic  factors. 

3.1  Application  Scope 

A  DDS  may  be  used  in  one  program,  for  a  single  project,  or  agency-wide.  It  may  inventory  and  document  only 
data  in  automated  systems,  or  it  also  may  describe  data  that  is  processed  manually.  A  Federal  agency  must  assess  its 
intended  scope  of  application  in  preparation  for  selection  of  a  DDS,  because  the  value  of  the  DDS  to  the  users 
depends  on  the  quality  of  the  software  selected,  and  on  the  quality  of  the  DDS  contents.  This  assessment  will  permit 
the  Federal  agency  to  determine  the  types  of  DDS  capabilities  fhat  are  required. 
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The  initial  scope  of  DDS  applications  within  an  agency  may  be  selected  either  by  specific  applications  (training, 
personnel,  procurement,  property,  etc.)  or  by  specific  types  of  entities  (COBOL  data  elements,  COBOL  programs, 
database  entities,  etc.).  Various  factors,  such  as  an  impending  application  conversion,  management  enthusiasm,  or 
available  personnel,  may  determine  a  preference  for  one  approach  over  the  other. 


3.2  Technical  Factors 

Once  the  scope  of  the  DDS  application  has  been  determined,  existing  DDS  systems  need  to  be  reviewed  to 
determine  if  they  meet  agency  requirements.  The  most  basic  consideration  for  an  agency  to  address  is  whether  or  not 
there  is  an  existing  DDS  that  will  operate  on  the  agency’s  existing  or  planned  hardware  and  under  the  existing 
version(s)  of  the  system  software.  All  existing  DDS’s  which  do  not  satisfy  the  hardware  and  system  software  criteria 
can  be  eliminated  from  further  consideration.  In  some  cases,  the  hardware /software  criteria  will  severely  limit  the 
agency’s  choice. 

Technical  analysis  of  the  remaining  available  systems  should  address  capabilities  discussed  in  section  2, 
including: 

*  The  prescribed  set  of  entity  types  and  associated  attributes  included  in  the  DDS  package.  In  addition,  the 
agency  must  determine  if  it  needs  the  capability  to  define  its  own  unique  entities,  attributes,  and  relationships.  If 
so,  the  agency  must  review  the  DDS  system  to  determine  if  this  facility  exists. 

*  The  type  of  DDS  that  is  needed  to  satisfy  agency  needs,  e.g.,  an  active  or  a  passive  DDS,  or  a  dependent  or 
an  independent  DDS.  This  latter  consideration  will  depend  on  whether  the  agency  has  a  DBMS  and  if  so  which 
DBMS. 

*  The  DDS  data  definition  facility  and  input  methods  in  terms  of  ease  of  use  relative  to  the  skill  level  of  the 
intended  users. 

*  Reporting,  documentation,  and  ad  hoc  query  capabilities  and  the  ease  of  using  these  capabilities. 

*  Security,  edit  validation,  backup,  recovery,  and  reorganization  facilities. 

*  Enhancement  capabilities,  e.g.,  the  ability  to  interface  user-written  code  with  the  DDS. 

*  Vendor  support  in  terms  of  training,  DDS  software  maintenance,  and  user  groups. 


3.3  Economic  Factors 

An  agency  that  is  prepared  to  obtain  a  DDS  has  three  options: 

1.  To  design  and  implement  its  own  DDS, 

2.  To  lease  or  purchase  a  commercial  system,  or 

3.  To  obtain  a  system  developed  by  another  Federal  agency. 

The  in-house  design  and  implementation  option  implies  a  high  initial  cost  both  in  terms  of  time  and  labor. 
However,  in-house  knowledge  about  the  DDS  software  should  reduce  subsequent  operational  and  maintenance  costs. 
Some  of  the  drawbacks  are:  the  system  is  usually  tailored  to  a  specific  application;  it  may  not  be  flexible  and 
responsive  to  changing  requirements;  and  it  may  not  be  transportable.  However,  if  none  of  the  existing  systems  fulfill 
agency  requirements,  this  is  one  of  the  feasible  options,  if  a  DDS  is  deemed  desirable. 

Although  the  purchase  or  lease  option  requires  lead  time  for  the  procurement  process,  the  commercial  systems 
generally  can  be  implemented  in  a  shorter  period  of  time  than  the  previous  option.  Less  manpower  is  usually  required 
to  install  and  maintain  a  commercial  package,  thereby  enabling  more  use  of  personnel  resources  in  problem-oriented 
analysis  and  standardization.  In  addition  to  the  initial  outlay  of  funds  to  purchase/lease  the  system,  there  will  also  be 
an  annual  maintenance  fee. 

The  third  option,  obtaining  a  system  developed  by  another  agency,  may  appear  to  be  the  most  economical. 
Developer-agencies  may  consent  to  provide  available  programs  and  documentation  to  other  interested  agencies,  either 
free  of  charge  or  for  a  nominal  administrative  fee  [2].  However,  it  is  not  likely  that  the  supplying  agencies  would  be 
prepared  to  provide  maintenance  for  either  “fixes”  or  enhancements.  The  acquiring  agency  will  be  “on  its  own,” 
except  for  informal  assistance.  Special  adaptation  of  the  software  to  fit  specific  agency  needs  would  need  to  be 
performed  by  the  acquiring  agency.  Another  drawback  is  that  documentation  may  be  sketchy  or  out  of  date. 
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4.  GUIDELINES  FOR  PREIMPLEMENTATION  PLANNING 

These  guidelines  describe  a  general  approach  that,  under  normal  circumstances,  will  produce  successful  DDS 
applications.  They  are  presented  with  a  view  toward  agency-wide  application  of  a  DDS.  Similar  steps  are  involved 
when  DDS  use  is  limited  to  only  one  office,  program,  or  project.  The  modifications  necessary  in  the  latter  case  are 
rather  obvious. 

Prior  to  the  installation  of  a  DDS,  management  must  resolve  several  important  issues.  The  issues  discussed  in 
this  section  are: 

*  DDS  policies  and  budgeting; 

*  data  standardization; 

*  control  and  coordination  of  DDS  contents; 

*  technical  support  of  the  DDS  software;  and 

*  training. 

4.1  DDS  Policies  and  Budgeting 

Because  DDS  planning,  budgeting,  and  management  normally  concern  and  affect  various  offices  and  activities 
within  an  agency,  an  integrated  and  unbiased  approach  is  best  produced  through  a  central  support  group.  Its  stature 
or  organizational  placement  must  be  such  that  its  findings  and  recommendations  are  widely  accepted. 

When  developing  and  using  the  DDS,  particularly  if  multiple  offices  are  involved,  a  steering  committee  should 
be  established  to  guide  and  assist  the  central  support  group.  The  formality  of  the  steering  committee  depends  on  the 
organization’s  policies.  At  the  very  least,  it  should  consist  of  an  informal  group  of  user  representatives.  The  steering 
committee  should  provide  information  on  the  impact — in  cost,  time,  and  any  interagency  reporting  requirements — of 
changing  existing  data  element  descriptions.  Committee  members  also  should  help  the  central  support  group  to 
communicate  the  benefits  of  the  DDS  to  users. 

Steering  committee  membership  should  be  representative  of  the  envisioned  DDS  users;  at  the  same  time, 
committee  size  and  composition  should  foster  effective  working  conditions.  Each  agency  must  review  the  scope  of  its 
DDS  applications  to  determine  desirable  user  representation.  Each  person  selected  should  support  the  use  of  the  DDS 
enthusiastically.  Each  steering  committee  member  can  be  a  key  person  in  minimizing  resistance  to  change  and 
mobilizing  support  for  the  DDS  by  keeping  the  user  organization  informed  about  the  DDS  and  its  anticipated  benefits. 
The  central  support  group,  with  concurrence  of  the  steering  committee,  should  have  the  authority  to: 

*  develop  a  budget  and  cost  allocations,  if  any,  for  DDS  design  or  acquisition,  implementation,  operation,  and 

training; 

*  finalize  the  initial  and  long-range  scope  of  DDS  application  and  formulate  the  associated  usage  policy;  and 

*  ensure  that  sufficient  staff  with  appropriate  skills  are  assigned  to  provide  the  technical  support  functions 

described  in  section  4.4. 

Too  often,  automated  systems  fail  to  produce  expected  benefits  because  inadequate  resources  are  allocated  to 
planning,  implementation,  long-term  operation,  and  training.  To  ensure  that  the  DDS  can  be  used,  and  is  used  in  the 
anticipated  manner,  sufficient  funds  and  appropriate  personnel  skills  must  be  devoted  to  implementing,  testing,  and 
maintaining  the  software  so  that  it  operates  effectively.  Resources  must  be  available  for  data  entry  and  standardization 
if  the  DDS  contents  are  to  be  up-to-date  and  reliable.  And,  resources  for  training  and  consultation  are  required  so  that 
users  know  how  to  use  the  DDS.  Additional  funds  and  staff  may  be  needed  for  each  new  application. 

Budget  formulation  approaches  range  from  developing  one  central  DDS  budget  to  having  decentralized  budgets 
for  each  using  group.  Costs  can  be  allocated  as  overhead  or  as  direct  costs  in  specified  program  areas.  Generally,  the 
approach  used  should  be  consistent  with  that  which  is  currently  used  by  an  agency  to  manage  its  other  resources  such 
as  equipment  and  facilities. 

The  required  policy  comprises  a  clear  and  unambiguous  management  directive  for  standardization  and 
management  of  data  and  information  as  a  priority  agency  objective.  Agency  offices  and  personnel  who  will  be  DDS 
users  must  understand  the  benefits  expected  from  the  DDS,  and  the  changes  expected  in  their  areas  of  responsibility, 
including  any  cost  and  personnel  allocations  for  use  of  the  DDS.  Users  must  also  be  told  the  procedures  that  will  be 
used  to  assure  compliance  with  standard  entity  descriptions,  and  to  resolve  conflicts  during  the  standardization 
process. 
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4.2  Data  Standardization 

Management  must  establish  a  data  standardization  activity,  and  designate  appropriate  responsibilities.  Data 
standardization  includes  all  the  actions  necessary  to  insure  the  consistent  definition  and  usage  of  data.  This  process 
determines  the  naming,  meaning,  and  coding  standard  for  data  elements  to  be  followed  by  all  users.  Data 
standardization  is  largely  an  intellectual  function.  The  DDS,  if  properly  used,  can  assist  in  that  function,  but  the  DDS 
cannot  perform  the  needed  analysis  and  formulation  automatically.  For  example,  a  DDS  cannot  automatically 
distinguish  between  homonyms:  two  data  elements  from  different  systems  with  the  same  name  but  with  different 
meanings.  An  example  is  “rank,”  meaning  either  military  rank  or  rank  in  a  series. 

A  well-defined  and  well-structured  set  of  data  standards  ensures  that  data  collected  in  the  DDS  for  one  purpose 
may  be  used  for  another  purpose.  If  the  DDS  is  the  source  of  established  standards,  it  can  be  used  as  an  enforcement 
mechanism  to  ensure  that  the  data  standards  are  being  used.  This  can  be  done  through  various  DDS-unique  functions, 
e.g.,  the  capability  to  check  the  validity  of  data  against  a  predetermined  set  of  criteria;  and  to  supply  standard  data 
definitions  to  requesting  components  such  as  a  DBMS  or  an  application  program. 

The  central  support  group  described  above  normally  should  have  the  data  standardization  responsibility,  which 
includes: 

*  determining  the  entity  type  that  will  be  standardized; 

*  developing  entity  standards,  and  modifying  standards,  if  necessary,  as  requirements  change; 

*  resolving  conflicts  that  develop  in  the  standardization  process;  and 

*  auditing  and  enforcing  DDS  standards. 

Depending  on  the  scope  of  DDS  application  and  the  breadth  of  an  agency’s  mission,  some  specialized 
standardization  functions  may  be  delegated  to  concerned  program  offices.  However,  the  central  support  group  should 
retain  the  responsibility  for  data  entities  used  by  more  than  one  organizational  unit  or  program  office. 

4.3  Control  and  Coordination  of  the  DDS  Contents 

A  critical  factor  in  the  effectiveness  of  the  DDS  is  the  currency  and  accuracy  of  the  content  of  the  DDS. 
Ultimately,  the  principal  management  goal  is  to  be  able  to  assure  that  the  DDS  content  is  consistent,  current,  and 
accurate.  The  central  support  group  should  have  the  responsibility  for  the  coordination  and  control  of  the  DDS 
contents.  Designated  staff  should  ensure  that  additions,  deletions,  or  changes  requested  by  one  using  organization  will 
not  adversely  affect  another  user. 

A  key  management  question  is:  Where  should  responsibility  for  formulating  new  entity  descriptions  and 
changing  operational  entities  be  located? 

Responsibility  for  adding,  changing,  and  deleting  DDS  entities  could  be  totally  centralized  in  the  central  support 
group.  Conversely,  if  standardization  responsibility  for  program  specific  entities  is  delegated  to  user  organizations,  the 
responsibility  for  the  addition  and  maintenance  of  these  entities  could  be  delegated  also.  In  the  latter  situation,  the 
central  support  group  would  continue  to  retain  the  responsibility  for  DDS  entities  that  are  pertinent  to  more  than  one 
program  area.  In  either  case,  staff  resources  will  be  needed  to  formulate  DDS  input  in  the  appropriate  manner  for 
processing  by  the  DDS  software. 

In  cases  where  users  of  the  DDS  are  allowed  to  change  or  add  entities  and  their  attributes,  the  control  and 
coordination  function  is  especially  critical.  This  situation  may  lead  to  the  undesirable  possibility  that  a  change  was 
made  to  an  entity  that  is  inconsistent  with  other  entities.  To  avoid  this,  users  must  follow  closely  the  procedures 
established  for  using  the  DDS.  They  must  consult  the  designated  coordinator  within  the  central  support  group  on 
proposed  changes,  to  ensure  that  there  is  no  conflict  with  other  entities.  The  central  support  group  must  arbitrate 
between  conflicting  proposals  and  determine  the  most  advantageous  course  of  action  for  the  agency. 

4.4  Technical  Support  of  the  DDS  Software 

The  DDS  is  a  sophisticated  software  system.  Trained  computer  personnel,  therefore,  must  be  responsible  for 
implementing  and  maintaining  the  software,  and  assisting  other  personnel  to  use  the  DDS  most  effectively.  The  range 
of  responsibilities  for  this  technical  staff  may  vary  depending  on  its  placement  within  the  organization. 

The  technical  support  staff  could  be  part  of  the  central  support  group.  This  organizational  placement  will  reduce 
conflicts  in  technical  priorities,  and  it  will  minimize  communication  barriers  between  the  technical  staff  and  the  staff 
working  on  DDS  policy,  budget,  and  standardization. 
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Policy  and  practical  considerations  may  make  it  more  feasible  to  have  the  DDS  technical  support  functions 
performed  by  system  programmers  in  the  ADP  division.  Such  an  organizational  placement  will  result  generally  in 
more  effective  utilization  of  technical  personnel.  During  periods  in  which  the  DDS  does  not  require  full-time 
commitment  of  technical  staff,  they  can  work  on  other  ADP  systems. 

Regardless  of  organization  placement,  the  technical  support  staff  should  have  the  responsibility  for: 

*  maintaining  the  DDS  software; 

*  ensuring  the  reliability,  security,  and  integrity  of  the  DDS  software  and  its  associated  database; 

*  ensuring  adequate  DDS  backup  and  recovery  capability; 

*  developing  any  special  computer  programs  to  interface  with  the  DDS  software  in  response  to  an  agency’s 

unique  requirements; 

*  consulting  with  users  and  assisting  them  in  the  use  of  the  DDS  on  an  as-needed  basis;  and 

*  evaluating  new  requirements  and  new  software. 

4.5  Training 

An  agency  will  require  training  for  three  distinct  types  of  individuals:  management,  programmatic  and  technical 
users,  and  data  management  users.  Responsibility  for  providing  training  should  be  assumed  by  the  central  support 
group,  although  they  may  be  assisted  by  technical  staff  and/or  training  specialists.  Training  strategies  differ  for  each 
type  because  of  the  different  goals. 

1.  Management  level  presentations  are  structured  as  overviews  of  technical  capabilities,  with  emphasis  on  the 
benefits  of  the  DDS  to  the  organization,  identification  of  known  system  limitations,  and  examples  of  potential 
application  areas  that  would  illustrate  how  the  managers  can  use  the  DDS  to  meet  their  responsibilities.  The  purpose 
of  these  presentations  is  to  promote  the  use  of  a  DDS  in  the  managers’  organizations. 

2.  User  level  training  emphasizes  those  features  that  programmatic  and  technical  end-users  are  likely  to  utilize, 
such  as  the  query  facility  and  reporting  capability.  User  training  includes  detailed  instructions  on  how  to  input  and 
change  entity  descriptions  in  the  DDS,  and  how  to  obtain  specific  information  from  the  DDS.  This  training  assists  the 
user  in  exploiting  DDS  features  and  in  circumventing  associated  software  operational  limitations. 

3.  Technical  level  training  addresses  the  data  management  staff,  e.g.,  programmers  and  systems  analysts  who 
must  maintain  the  DDS  software.  This  training  presents  detailed  technical  information  about  the  DDS  software,  its 
functions,  interfaces  with  other  software  components,  and  special  DDS  software  features. 


5.  GUIDELINES  FOR  USING  A  DDS 

These  guidelines  provide  guidance  on  how  to  use  a  DDS  once  it  is  acquired.  This  section  discusses  both 
initiation  and  operational  considerations  in  using  a  DDS. 

5.1  Initiating  the  DDS 

This  section  presents  a  suggested  scenario  on  how  an  agency  initiates  a  DDS.  An  agency  should  have  reached  the 
following  state  of  readiness: 

*  The  decision  to  use  a  DDS  has  been  made. 

*  The  DDS  is  already  in  place,  or  is  currently  being  installed. 

*  Initial  management  decisions  have  been  made,  including: 

-  assessment  of  costs  and  benefits  for  using  a  DDS, 
establishment  of  a  central  support  group, 
formation  of  a  steering  committee, 

-  designation  of  a  person  with  the  authority  to  resolve  intra-agency  conflicts  over  DDS  entries, 

-  designation  of  person(s)  responsible  for  defining,  updating,  and  maintaining  the  DDS. 
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The  following  represents  a  reasonable  approach  to  initiating  a  DDS.  The  suggested  chronology  may  vary  from  agency 
to  agency: 

1.  The  central  support  group,  with  concurrence  of  the  steering  committee,  selects  the  organizational  unit  or 
project  that  will  be  the  pilot  application.  The  application  selected  should  have  a  high  likelihood  of  success,  but  should 
present  also  a  significant  need. 

2.  The  central  support  group  defines  criteria  to  confirm  successful  installation  of  the  DDS — criteria  that  can  be 
used  in  acceptance  testing  in  the  case  of  a  purchased/leased  DDS. 

3.  The  central  support  group,  assisted  by  user  representatives  from  the  steering  committee,  identifies  pertinent 
data  and  processing  entities  for  initiating  the  DDS.  Sources  of  information  necessary  to  define  these  entities  must  be 
collected.  These  sources  include  the  principal  forms,  reports,  programs,  files,  and  systems  that  the  agency  uses.  The 
entity  descriptions  selected  for  inclusion  in  the  DDS  database  should  be: 

-  descriptions  of  commonly  used  data  elements,  records,  files,  databases,  computer  programs,  and 
computer  reports; 

-  information  identifying  forms  and  their  use; 

-  information  identifying  source  documents,  their  purpose,  type,  origin,  destination,  disposition,  and 
relationship  to  other  entities; 

-  information  on  paper  records,  such  as  official  documents  to  be  submitted  to  a  designated  office,  e.g.,  the 
documents  that  must  be  kept  to  support  tax  reports. 

4.  The  central  support  group  establishes  naming  conventions  and  other  standards  for  all  entities,  and  obtains 
steering  committee  review  and  approval.  The  central  support  group  then  either  performs  the  following  tasks  or 
delegates  them  to  the  initial  user  organization: 

-  Define  and  describe  the  types  of  entities  listed  above.  The  descriptions  should  detail  physical 
characteristics,  usages,  relationships,  ownership,  and  dates  of  creation  or  change. 

-  Determine  and  describe  relationships  among  the  entities. 

-  Determine  and  describe  information  flow,  authority,  and  security  information,  etc. 

5.  The  steering  committee,  which  represents  the  needs  of  individual  user  organizations,  determines  the  various 
reports  that  users,  managers,  database  administrators,  and  analysts  need  from  the  DDS.  These  reports  are  then 
defined  by  the  central  support  group  for  any  necessary  programming. 

6.  The  technical  staff  loads  the  data  descriptions  into  the  DDS  and  starts  experimental  use.  As  part  of  this 
activity,  they: 


-  Select  the  most  efficient  way  of  loading  the  data.  Each  DDS  offers  different  facilities  for  initial  loading 
of  the  data.  Some  offer  batch  bulk  loading  mechanisms  for  start-up  situations,  while  others  offer  only  online 
transaction-oriented  facilities. 

-  Load  pilot  applications  against  the  DDS,  define  sample  queries  and  sample  reports  to  test  the  DDS. 

-  Identify  redundancy  areas,  conflicts,  and  errors  for  resolution.  They  work  with  DDS  planners  and  users 
to  resolve  these  problems. 


7.  The  central  support  group  ensures  that  affected  end-users  (e.g.,  application  specialists,  managers,  and  others) 
are  trained  to  use  the  DDS. 

8.  The  steering  committee  and  the  central  support  group  jointly  develop  a  priority  list  for  other  organizations 
and  projects  to  initiate  advance  planning  for  subsequent  application. 


Subsequent  projects  and/or  organizational  units  are  added  by  a  similar  process.  Once  initiated,  DDS  applications 
may  be  incrementally  expanded  to  the  limit  of  available  resources  or  the  perceived  limit  of  effective  automation. 
Residual  entities  and  applications  may  be  catalogued  by  simplified  manual  methods  (and  also  with  program  library 
techniques  for  computer  applications). 

As  additional  application  areas  increase  the  size  of  the  DDS  database,  opportunities  for  redundancy  and  conflict 
increase  significantly.  Resolution  of  these  must  be  consistent  with  previously  established  standards. 
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5.2  Operational  Considerations 

After  the  DDS  becomes  operational,  the  central  support  group  and  the  technical  staff  must  continue  to  perform 
the  functions  described  in  section  4.  In  summary,  the  central  support  group  responsible  for  managing  the  DDS  must 
undertake  the  following  tasks: 

1.  Develop  the  DDS  budget  and  review  the  resource  utilization  for  all  functions  associated  with  the  operation  of 
the  DDS. 

2.  Maintain  standardization,  control,  and  coordination  procedures  to  ensure  that  pertinent  and  current 
information  is  in  the  DDS. 

3.  Audit  and  enforce  DDS  standards. 

4.  Propose  the  new  applications  that  should  be  admitted  to  the  DDS. 

5.  With  the  assistance  of  the  steering  committee,  resolve  conflicts  that  may  arise  from  new  applications  such  as 
conflicting  usage  and/or  definition  of  data. 

6.  Ensure  that  the  DDS  software  is  adequately  maintained,  that  backup  and  recovery  software  function 
properly,  and  that  any  required  new  capabilities  are  implemented. 

7.  Monitor  error  rates.  If  they  are  high,  data  entry  and  error  correction  methods  and  procedures  must  be 
reviewed. 

8.  Provide  advocacy  presentations,  training,  and  consultation  to  the  rest  of  the  organization  on  the  use  of  the 

DDS. 

9.  Train  new  users.  Training  would  include  an  overview  of  the  capabilities  of  the  DDS,  who  can  benefit  from 
its  use,  how  the  DDS  is  used  to  formulate  queries  or  to  report  desired  information,  and  what  kind  of  data  already 
exists. 

In  addition,  the  central  support  group  must  review  DDS  usage.  Data  entry  staff,  particularly  if  they  are 
individuals  with  little  ADP  experience  may  require  additional  technical  assistance,  or  data  entry  aids.  For  example, 
pre-formatted  forms  and  display  screens  help  reduce  errors  of  omission  and  errors  in  field  size.  Likewise,  error 
messages  must  be  easily  understood  and  they  must  be  received  in  a  timely  manner  in  order  to  ensure  that  DDS 
contents  are  accurate  and  up-to-date. 

Users  should  be  periodically  interviewed  to  assess  if  DDS’s  reports  are  informative,  easy  to  use,  and  received  in 
time  to  be  useful.  The  ad  hoc  query  capability  also  needs  to  be  assessed  to  determine  its  usability,  and  to  ascertain 
whether  additional  user  training  and  consultation  are  required. 

Finally,  the  expected  benefits  that  can  be  achieved  from  using  a  DDS  must  be  reviewed  to  determine  if  they  are 
being  realized.  For  example,  a  major  potential  DDS  benefit  is  its  use  as  a  documentation  aid  during  the  system 
development  life  cycle.  Is  the  DDS  being  used  in  the  anticipated  (recommended)  manner?  If  it  is  not,  the  central 
support  group  must  review  such  factors  as  user  awareness  of  DDS  existence  and  capabilities,  ease  of  use,  training,  and 
system  response  time. 
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